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ABSTRACT 


Military  system  acquisition  management  decisions  can  be  both 
untimely  and  uninformed,  according  to  the  author,  due  to  the 
adverse  effects  of  communication  breakdown  and  filtering  of 
information.  An  acquisition  group  decision  support  system 
(AGDSS) ,  defined  in  this  thesis,  seeks  to  maintain  acquisition 
team  integrity  and  provide  the  necessary  information  processing 
capacity  to  mitigate  the  impact  of  these  effects.  The  combina¬ 
tion  of  such  key  technologies  as  local  area  networks,  word 
processing,  graphics,  data  base  management,  and  video  confer¬ 
encing,  is  employed,  which  can  free  acquisition  team  members  of 
mundane  paperwork  and  afford  them  extraordinary  decision  making 
capabilities.  These  capabilities  promise  to  result  in  more 
timely  and  better  informed  decisions.  An  example  is  provided  to 
illustrate  the  application  of  an  AGDSS  to  an  acquisition-related 
problem  and  to  show  the  benefits  that  can  be  derived  from  the 
output  of  the  AGDSS.  Finally,  a  system-level  specification 
describing  the  performance  and  interface  requirements  is  pre¬ 
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I.  ACQUISITION  GROUP  DECISION  MAKING 


Military  system  acquisition  management  decisions  are 
made  on  a  variety  of  programmatic  issues  related  to  program 
management  and  functional  areas,  such  as  configuration  man¬ 
agement,  contracting,  engineering,  logistics,  manufacturing, 
program  control,  and  test.  Examples  include  the  approval  of 
a  design  change,  the  procurement  of  additional  spare  parts, 
the  setting  of  production  increments,  the  approval  of  func¬ 
tional  and  physical  configuration  audits,  the  synthesis  of 
budget  forecasts,  and  the  exercise  of  contract  options. 

The  above  decisions  are  acknowledged  by  the  Defense 
Systems  Management  College  to  be  usually  made  by  consensus 
(Sellers,  1985,  p.  1.5d),  because  the  program  manager  or  his 
functional  managers  cannot  make  a  decision  in  one  functional 
area,  such  as  an  engineering  issue,  without  a  collateral 
impact  on  one  or  more  of  the  other  functional  areas.  In 
addition,  time  and  money  are  two  constraints  that  enter  into 
the  decision  making  process.  There  is  never  enough  of 
either  one.  Acquisition  schedules  all  too  often  are  overly 
ambitious  and,  as  such,  are  unrealistic,  resulting  in  less 
than  optimum  decisions.  Where  Research  &  Development  (R&D) 
is  involved,  there  is  little  knowledge,  if  any,  of  the  true 
capabilities  of  a  contractor  to  support  the  R&D  activity 
within  the  time  and  budget  allotted.  Furthermore,  schedule 
slips  and  cost  overruns  incurred  during  R&D  tend  to  compli¬ 
cate  the  time  and  money  constraints  associated  with  produc- 
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tion.  Occasionally,  the  acquisition  team  members  are  absent 
or  preoccupied  with  other  programs  (as  is  common  with  ma- 
trixed  organizations) ,  and  decisions  are  made  without  a  full 
team's  consent.  Frequently,  the  entire  team  must  be  gath¬ 
ered  together  for  discussion  and/or  be  engaged  in  extensive 
research-discussion  cycles.  The  latter  can  result  in  weeks 
of  deliberation  which  may  lead  to  other  problems.  Absence 
of  team  members  and  lengthy  deliberations  provide  for  what 
the  author  defines  as  untimely  and/or  uninformed  decisions. 

Program  management  decisions  generally  result  from  a 
collection  of  inputs  and  or  factors  (Sellers,  1985,  1.5c) 
which  are  in  and  of  themselves  time  sensitive  in  most  if  not 
all  cases.  Because  the  circumstances  governing  the  decision 
making  process (es)  are  varied,  subject  to  change,  and  in 
some  instances  nondeterministic,  a  structured  environment 
does  not  lend  itself  well  to  providing  a  feasible  approach 
to  problem  resolution.  For  instance,  a  manager  is  briefed 
regularly  on  the  functional  status  (engineering,  logistics, 
manufacturing)  of  his  or  her  program.  Each  functional  area, 
albeit  an  integral  part  of  the  remaining  areas  is  segregated 
for  management  oversight.  Despite  the  manager's  skill  to 
delegate  to  his  or  her  functional  experts,  the  segregation 
of  responsibility  leads  to  the  occurrence  of  "holes”  in  the 
management  umbrella.  Things  inevitably  "slip  through  the 
cracks",  either  because  the  dispersion  of  program  team 
members  within  a  matrixed  organization  causes  communication 
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breakdown  or  because  unforeseen  events  occur.  Likewise,  the 
program  manager  is  routinely  responsibile  for  reporting  a 
program's  status  regarding  such  issues  as  funding,  sched¬ 
ule^),  and  progress  on  resolution  of  test  discrepancies  to 
his  or  her  boss*  (Sellers,  1985,  p.  1.5c).  When  a  program 
is  in  its  infancy,  all  indicators  are  generally  satisfactory 
(green) .  Then  as  time  passes,  milestones  begin  to  slide  and 
problems  begin  to  surface.  If  dealt  with  up  front  the 
impact  of  these  problems  can  be  reduced.  However,  more 
often  than  not,  things  are  neglected  or  hidden  until  it  is 
too  late  to  capitalize  on  opportunities  beneficial  to  the 
outcome.  This  benign  neglect  can  be  attributed  to  the 
inherent  nature  of  the  acquisition  environment,  where  a 
preponderence  of  data,  systems,  and  dynamics  of  schedules 
necessitates  the  filtering  of  information.  This  filtering 
seeks  to  limit  the  quantity  of  information  as  well  as  the 
alternative  decisions  the  decision  maker  has  available. 
Decision  outcome(s)  is/ (are)  made  based  on  neither  all  the 
information  available  nor  the  flexibility  given  by  weighing 
the  feasible  options.  Neglecting  to  consider  all  the  fac¬ 
tors  and  options  regarding  a  decision  imposes  a  bias(struc- 


*  The  term  boss  shall  hereafter  be  referred  to  as  the 
director  of  programs,  the  title  given  to  the  author's  imme¬ 
diate  supervisor  while  the  author  served  as  program  manager. 
The  director  of  programs  is  a  middle  management  position  and 
should  not  be  confused  with  the  newly  created  executive 
level  position  of  program  executive  officer  (PEO) . 
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ture)  on  the  decision  making  process.  This  structure  may 
lead  to  an  untimely  and/or  uninformed  decision. 

The  untimely  and/or  uninformed  decision  is  an  extremely 
common  one  that  to  date  has  repeatedly  led  to  the  acqui¬ 
sition  of  systems  that  did  not  perform  to  the  intended 
specifications.  Not  only  have  systems  been  accepted  into 
the  inventory  at  substandard  performance  levels,  but  as  a 
result,  down  the  road  these  systems  may  accrue  a  higher  life 
cycle  cost,  or  compromise  operator  safety,  and  can  also 
result  in  a  mutual  distrust  between  government  and  indus¬ 
try  . 

A  group  decision  support  system  (GDSS)  can  provide 
acquisition  team  decision  makers  the  best  information  re¬ 
sources  possible  with  which  to  formulate  and  execute  their 
decisions.  It  can  do  so  by  maintaining  team  integrity  on  a 
dcily  basis  as  well  as  maintaining  corporate  knowledge  when 
personnel  get  reassigned.  The  physical  implementation  of  a 
GDSS  is  the  local  decision  network  (LDN)  (see  Figure  1, 
Desanctis  and  Gallupe,  1985,  p.195).  The  LDN  is  a  local 
area  network  (LAN)  of  individual  decision  support  system 
( DSS )  terminals.  In  addition  to  the  standard  LAN  protocols, 
the  LDN  requires  facilities  to  control  both  how  and  what 
type  of  information  should  be  exchanged  (see  APPENDIX  p.  2, 
para.  3. 1.1.1).  Aside  from  its  importance  as  a  communica¬ 
tions  link  any  further  discussion  of  the  LAN  portion  of  the 
GDSS  is  reserved  for  the  system  specification  found  in  the 
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APPENDIX.  Thus  only  the  DSS  is  explored  further  in  this 
document.  The  enhanced  capability  to  seize  opportunities  as 
well  as  to  seek  additional  initiatives  is  facilitated  by  an 
acquistion  group  decision  support  system  ( AGDSS)  (for  both 
government  and  contractor) .  It  can  provide  for  a  more 
effective  acquisition  environmment . 

The  AGDSS ' s  primary  role  would  be  to  both  coordinate  and 
facilitate  the  daily  transfer  of  information  among  program 
team  members  and  to  aid  the  decision  processing  needs  of  the 
program  manager  and  the  team.  Secondly,  the  AGDSS  would  be 
tasked  to  provide  reports  to  the  director  of  programs  as 
required.  Finally,  the  AGDSS  would  support  "what  if"  type 
decision  making,  that  is  foresighted  with  the  goal  of  deter¬ 
mining  current  decisions  by  which  to  avert  problems  down¬ 
stream.  The  "what  if"  capacity  of  the  AGDSS  would  also  be 
helpful  in  searching  for  possible  schedule  slips  or  other 
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program  impacts  due  to  potential  risk  taking  on  the  part  of 
the  program  manager. 

In  order  to  maintain  the  continuity  of  corporate  knowl¬ 
edge  as  personnel  are  reassigned,  the  AGDSS  would  provide, 
via  its  libraries,  repositories  of  information.  Unlike 
traditional  Management  Information  Systems/Electronic  Data 
Processing  (MIS/EDP)  systems,  this  data  will  be  more  poten¬ 
tially  exploitable  by  the  successors  of  those  that  create  it 
via  the  flexibility  and  unstructured  design  of  the  AGDSS 
subsystems . 
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II.  INTRODUCTION  TO  DECISION  SUPPORT  SYSTEMS 


A.  DEFINITION 

A  decision  support  system  (DSS)  is  an  interactive  com¬ 
puter-based  system  to  aid  decision  makers  in  utilizing  data 
and  models  toward  the  solution  of  unstructured  problems 
(Sprague  and  Carlson,  1982,  p.  4).  The  distinction  between 
structured  versus  unstructured  problems  is  fundamental  to 
understanding  the  difference  between  traditional  computer 
systems  and  DSS.  The  former  employ  structured  algorithms 
which  must  be  executed  sequentially  with  little  or  no  oppor¬ 
tunity  for  user  modification.  A  DSS,  on  the  other  hand, 
affords  the  user  the  flexibility  to  alter  both  the  content 
and  sequence  of  the  programs;  hence  the  reason  for  their 
being  characterized  as  unstructured.  The  interactive  nature 
of  the  system,  to  include  widespread  sharing  of  data  and 
program  modules,  results  in  a  unique  modeling  capability 
with  a  DSS. 

B.  THE  DSS  IN  THE  INFORMATION  WORLD 

1.  The  Connotational  View 

Figure  2  (Sprague  and  Carlson,  1982,  p.  7)  shows  the 
relationship  between  three  levels  of  sophistication  in  the 
information  systems  world.  EDP  as  the  first  of  these 
continues  to  perform  the  basic  operations  of  data  storage 
and  processing  with  summary  reports  (little  more  than  data 
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Decision  focus 


Figure  2  The  Connotational  View 
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listings)  for  management  as  its  major  product.  MIS  improved 
on  the  EDP  concepts  of  planning  and  integration  at  the 
operational  level,  providing  middle  management  with  informa¬ 
tion  management  via  data  base  capabilities.  A  need  to 
provide  executive  management  with  a  decision  aid  remained 
largely  unaddressed  by  EDP/MIS  technology.  A  DSS  can  pro¬ 
vide  top  managers  as  well  as  their  subordinates,  with  quick, 
user  friendly,  and  individually  tailored  decision  support. 

2 .  The  Theoretical  View 

From  a  theoretical  standpoint  a  DSS  is  looked  upon 

as : 

Dedicated  to  improving  the  performance  of  knowledge 
workers .. .whose  primary  job... is  the  handling  of  inform¬ 
ation  in  some  form... in  organizations  through  the  appli¬ 
cation  of  information  technology.  (Sprague  and  Carlson, 
1982,  p.  8) 

Figure  3  (Sprague  and  Carlson,  1982,  p.  9)  depicts  in  a 
classical  sense  the  dimensions  of  an  information  system. 
Levels  of  management  are  represented  vertically  and  func¬ 
tional  activities  are  represented  horizontally  and  labeled 
as  "Interactive  models",  where  the  acronyms  OR/MS  and 
DC/OA/WP,  represent  Operations  Research/Management  Science 
and  Data  Communications/Operations  Analysis/Word  Processing 
respectively. 

The  third,  or  systems  dimension  is  comprixed  of  informa¬ 
tion  systems  providing  support  to  the  knowledge  workers. 
While  advances  in  office  automation  and  telecommunications 
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improve  the  performance  of  these  systems,  the  combination 
of  information  technology  and  operations  research/management 
science  via  interactive  modeling,  pushes  the  evolution  of 
the  DSS . 

C.  VIEWPOINTS 

The  process  of  building  a  DSS  is  looked  upon  from  three 
viewpoints;  those  of  the  users,  the  builders,  and  the  tool- 
smiths.  The  users  are  concerned  with  the  problem  solving  or 
decision-making  task  support  that  the  DSS  will  provide.  The 
builders'  interest  lies  in  designing  capabilities  into  the 
DSS  to  support  the  users.  The  toolsmiths  involve  themselves 
with  the  integration  software  to  form  DSS  generators  in 
support  of  the  builders. 

From  the  users'  perspective,  DSS  performance  can  be 
measured  in  terms  of  performance  objectives.  The  builders 
view  DSS  performance  in  terms  of  three  characteristics:  (1) 
user  interface  (dialog  handling),  (2)  data  base  and  data 
base  management,  and  (3)  modeling  and  analytic  capability. 
The  toolsmiths  share  the  builders'  view  but  focus  on  the 
underlying  architecture  of  these  characterises. 

1 .  The  User 

The  following  paragraphs  describe  six  performance 
objectives  by  which  a  user  measures  DSS  performance. 

a.  Semistructured/Unstructured  Decision  Support 

EDP/MIS  are  of  little  use  in  this  environment  of 
underspecified  problems  where  the  structure  of  the  decision 
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process  depends  significantly  upon  the  style  of  the  decision 
maker. 

b.  Multi-level  Decision  Support 

Users  at  all  levels  of  the  decision  making 
process  require  integration  and  coordination  of  their  ef¬ 
forts  toward  total  problem  solution. 

c.  Independent/Interdependent  Decision  Support 

The  former  provides  a  decision  maker  sole  au¬ 
thority  for  a  decision  whereas  the  latter  connotes  the 
sharing  of  the  decision  making  process  with  others.  Sequen¬ 
tial  interdependent  decision  support  is  the  passing  along  of 
a  decision  to  successive  decision  makers  for  action.  Pooled 
interdependent  decision  support  results  in  arbitration  among 
decision  makers. 

d.  Multi-phase  Decision  Support 

Figure  4  illustrates  Simon's  Intelligence, 
Design,  Choice  (IDC)  paradigm  (Sprague  and  Carlson,  1982, 
p.26),  a  three-phase  decision  making  model.  The  double 
headed  arrows  at  the  left  of  the  figure  indicate  a  series  of 
feedback  loops  among  the  phases  of  this  operations  process: 

Intelligence  -  Acquiring  information  about  the 
environment,  processing  that  information  for  clues  leading 
to  conditions  requiring  decision  making. 

Design  -  Problem  formulation  and  testing  the 
feasibility  of  possible  solutions. 
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Figure  4  Phases  of  Decision  Making 


Choice  -  Choosing  from  the  selection  of  possible 
solutions  and  implementing  that  choice, 
e.  Process  Independent 

The  DSS  must  have  the  ability  to  support  a 
variety  of  decision-making  processes.  Rather  than  depend  on 
a  particular  process  it  must  instead,  both  conform  to  the 
individual  cognitive  style  of  the  decision  maker  and  be 
under  his  or  her  control. 
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f.  Ease  of  Use 


The  DSS  must  be  user  friendly  and  flexible  in 
order  to  attract  user  allegiance.  For  unlike  the  EDP/MIS 
environment,  decision  makers,  by  virtue  of  their  position  in 
the  organization,  can  refuse  to  be  inconvenienced  or  intimi¬ 
dated  by  a  computer  system,  especially  if  it  doesn't  meet 
their  needs. 

2.  The  Builder 

Although  the  builder  has  the  option  to  construct  the 
DSS  from  DSS  Tools  (hardware  and  software  used  to  develop 
DSS  generators) ,  it  is  usually  more  practical  to  use  DSS 
generators  possessing  initial  capabilities  which  can  be 
modified  to  satisfy  the  user's  needs  based  on  changes  in  the 
environment,  tasks,  and  the  user  (see  Figure  5,  Sprague  and 


Figure  5  The  Decision-Making  System 
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Carlson,  1982,  p.  28).  The  initial  DSS  can  be  thought  of  as 
a  succession  of  black  boxes  containing  subsystems  within 
each.  Referring  to  Figure  6  (Sprague  and  Carlson,  1982, 
p.  29) ,  within  the  DSS  box  are  the  data  base,  model  base, 


The  DSS 


Figure  6  Components  of  the  Decision  Support  System 
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and  a  software  system  which  is  further  comprised  of  dialog 
generation  and  management  software  (DGMS) ,  data  base  manage¬ 
ment  software  (DBMS) ,  and  model  base  management  software 
(MBMS)  . 

a.  The  Dialog  Subsystem 

While  the  user,  terminal,  and  software  comprise 
the  components  of  this  subsystem,  the  experience  (Sprague 
and  Carlson,  1982,  p.  30)  consists  of  the  action  language, 
the  display  or  presentation  language,  and  the  knowledge  base 
(see  Figure  7,  Sprague  and  Carlson,  1982,  p.  30).  The 


Knowledge 

base 


Figure  7  The  Dialog  Subsystem 


action  language  is  the  means  by  which  the  user  communicates 
with  the  system,  a  mouse  or  keyboard  for  example.  The 
presentation  language  is  what  the  user  sees  such  as  a  screen 
or  printer  output.  Finally,  the  knowledge  base  is  the 
knowledge  the  user  brings  to  the  system, 
b.  The  Data  Subsystem 

Figure  8  (Sprague  and  Carlson,  1982,  p.  31) 
illustrates  the  extensions  of  the  DSS  data  base  which  sug¬ 
gest  the  DSS  demands  more  from  its  data  base  management 
system  than  an  EDP/MIS  system.  In  addition  to  its  internal 


C 

o 


Figure  8  The  Data  Subsystem 
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data  ,  the  DSS  requires  data  from  external  sources  to  ac¬ 
quire  the  information  necessary  for  decision  making.  To 
accomplish  this,  the  data  subsystem  has  a  data  capture  and 
extraction  capability  for  rapid  access  and  update  of  data. 

c.  The  Models  Subsystem 

The  capability  derived  from  this  subsystem  to 
integrate  data  retrieval  and  reporting  from  EDP  with  tech¬ 
niques  from  the  management  science  arena  are  what  distin¬ 
guish  the  DSS's  potential  from  that  of  its  predecessors  as  a 
decision  aid.  Figure  9  (Sprague  and  Carlson,  1982,  p.33) 
illustrates  the  models  subsystem  component.  The  models  are 
assembled  from  a  set  of  building  blocks  much  like  subrou¬ 
tines.  A  set  of  model  management  functions  similar  to  those 
of  data  base  management  provide  the  capability  to  assemble, 
catalog,  and  interrelate  the  models  quickly  and  easily. 

3.  The  Toolsmith 

The  toolsmith  is  involved  with  the  science  and  engi¬ 
neering  aspects  of  information  technology  in  relation  to  the 
builder's  model  of  DSS  previously  described.  Experimental 
and  theoretical  work  continues  in  systems  requirements  for 
dialog  management.  Improvements  in  handling  both  time 
series  data  and  probabilistic  data  are  sought  for  data 
management.  Finally,  artificial  intelligence  (AI)  is  ex¬ 
pected  to  expand  upon  existing  what  if  modeling  capability 
derived  from  the  formulation  of  interrelationships  between 
variables . 


18 


Model  base 


Figure  9  The  Models  Subsystem 
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D.  THE  REPRESENTATIONS,  OPERATIONS,  MEMORY  AIDS,  CONTROL 
MECHANISMS  (ROMC)  FRAMEWORK 

The  (ROMC)  Framework  provides  a  process  independent 
approach  to  systems  analysis  for  DSS. 

1.  Representations 

Decision  makers  must  physically  represent  infor¬ 
mation  or  media  such  as  paper,  blackboards,  transparencies, 
etc.  to  communicate  some  concept.  The  following  are  some 
examples  in  the  IDC  format: 

Intelligence 

-  Identify  problem  to  be  solved 

-  Formulate  objective  function  and  con¬ 
straint  equations 

-  Write  the  equations 
Design 

-  Load  and  run  the  equations  in  a  linear 
program 

-  Modify  the  equations 
Choice 

-  Compare  range  of  feasible  solutions 

-  Select  the  appropriate  solution 
2 .  Operations 

As  discussed  previously  the  IDC  model  describes  the 
operations  process.  The  following  illustrates  some  examples 
in  the  IDC  format: 
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Intelligence 

-  State  the  problem 

-  Develop  a  plan 

-  Organize  a  team 

-  Implement  the  plan 

-  Manage  the  plan's  implementation 
Design 

-  Conduct  fact  finding  to  obtain  informa¬ 
tion 

-  Organize  the  information 

-  Validate  the  findings 

-  Evaluate  the  facts 

-  List  the  options 

-  Consider  the  associated  risks  for  each 
option 

Choice 

-  Compare  the  risks 

-  Choose  an  option 

-  Justify  the  choice 

3 .  Memory  Aids 

Memory  Aids  support  the  use  of  representations  and 
operations  as  illustrated  below: 

-  A  data  base  from  sources  internal  and  external  to  the 
organization 

-  Views (aggregations  and  subsets)  of  the  data  base 

-  Workspaces  for  displaying  the  representations  and  for 
preserving  intermediate  results  as  they  are  produced 
by  the  operations 

-  Libraries  for  saving  workspace  contents  for  later  use 
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-  Links  for  remembering  data  from  one  workspace  or 
library  that  is  needed  as  a  reference  when  operating 
on  the  contents  of  another  workspace 

-  Triggers  to  remind  a  decision  maker  that  certain 
operations  may  need  to  be  performed 

-  Profiles  to  store  default  and  status 
data  (Sprague  and  Carlson,  1982,  p.  104) 

4 .  Control  Mechanisms 

Control  mechanisms  aid  the  decision-maker  in  utiliz¬ 
ing  representations,  operations,  and  memory  aids  in  the 
decision-making  process  in  accordance  with  their  individual 
cognitive  abilities.  The  mechanisms  range  from  menus  or 
function  keys  to  help  commands  and  procedures  for  adding  or 
modifying  commands. 
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III.  THE  DESIGN  AND  IMPLEMENTATION  PLAN  FOR  THE  AGDSS 


A.  DESIGN  CONSIDERATIONS  FOR  THE  AGDSS 

The  AGDSS  will  support  an  iterative  design  capability 
with  a  configuration  that  is  flexibile  to  change  as  the 
needs  of  its  users  evolve.  It  will  be  developed  in  accord¬ 
ance  with  the  ROMC  framework  with  the  following  capabili¬ 
ties  : 

1.  Automate  the  storage,  processing,  and  retrieval  of 
documentation 

2.  Generate  reports,  including  graphics  and  spreadsheats 

3.  Provide  windows  containing  integrated  text,  graphics, 
and  video  displays 

4 .  Support  local  area  networking 

5.  Be  easy  to  use. 


B.  SYSTEM  CHARACTERISTICS 

The  AGDSS  consists  of  computer  terminals  networked 
together.  The  acquisition  team  will  use  the  system  to 
conduct  group  decision  making  via  menu  configurations  corre¬ 
sponding  to  program  management  and  functional  area.  All 
AGDSS  terminals  will  have  identical  main  menus.  The  submenu 
configurations  fall  into  three  basic  categories: 

1.  Task  menus  listing  management  or  functional  area  tasks 

2.  Window  setup  menus  for  display  of  multimedia  sources 
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of  documentation,  correspondence,  spreadsheet,  graph 
ics,  and  video. 

3.  Communications  menus  configuring  communication  modes 
and  channels. 

C.  AGDSS  SUBSYSTEM 

1.  The  Dialog  Subsystem 

a.  Using  the  ROMC  Approach 

The  dialog  subsystem  corresponds  to  the  repre¬ 
sentations  and  control  mechanisms  of  the  ROMC  approach. 

The  AGDSS  terminals  will  utilize  window  software  to  parti¬ 
tion  screen  displays  combining  video,  text,  and  graphics 
from  a  variety  of  sources  as  is  illustrated  in  the  following 
example. 

b.  Example  for  the  Dialog  Subsystem 

Suppose  the  program  manager  has  just  been  con¬ 
fronted  with  the  following  problem:  the  contractor  writes 
the  government  to  contest  failing  a  government  conducted 
test  of  a  device.  The  program  manager,  with  the  consulta¬ 
tion  of  the  test  and  engineering  functional  managers,  must 
decide  whether  or  not  the  test  procedure  involved  in  the 
test  is  valid  or  is  overspecified.  If  valid,  does  a  con¬ 
tractual  obligation  exist?  If  so,  is  it  beneficial  to  the 
government  to  uphold  its  position? 
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c.  Dialog  Sequence 

The  above  decision  is  indeed  complex,  and  will 
call  for  something  similar  to  the  following  dialog  sequence 
to  provide  the  program  manager  with  a  set  of  feasible  solu¬ 
tions  to  the  problem. 

(1)  Main  Menu.  The  program  manager  will  ini¬ 
tialize  the  AGDSS  by  selecting  "Program  Management"  from  the 
Main  Menu  which  will  bring  up  the  Program  Management  Task 
Menu  (see  Figure  10) . 


r  > 


Main  Menu 

1  Program  Management 

2  Configuration  Management 

3  Contracting 

4  Engineering 

5  Logistics 

6  Manufacturing 

7  Program  Control 

8  Test 


Select  Option  <l-8> 


Figure  10  Main  Menu 
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(2)  Program  Management  Task  Menu.  The  program 
manager  selects  "Correspondence”,  "Documentation",  and 
"Problem  Solving"  from  the  Program  Management  Task  Menu  to 
acquire  information  about  and  to  build  a  model  for  a  deci¬ 
sion  making  process  to  solve  the  problem  (see  Figure  11) . 
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Program  Management  Task  Menu 

1  Budget 

2  Communication 

3  Correspondence 

4  Documentation 

5  Schedules 

6  Meetings 

7  Problem  Solving 

Select  Option  <l-7> 


V _ J 


Figure  11  Program  Management  Task  Menu 


(3)  Information  Windows.  The  program  manager 
will  use  Information  Windows  to  display  the  Problem,  "What 
if",  and  references,  to  the  Test  Procedure,  Specification, 
and  Contract  (see  Figure  12) . 
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Information  Windows 


Problem  .  "What  if" 


Test  Procedure  .  Contract 


Specification 


Figure  12  Information  Windows 

(4)  Modeling  Windows.  After  reviewing  the 
documentation  and  reflecting  on  the  problem,  the  program 
manager  uses  the  Modeling  Windows  to  call  the  "Linear  Pro¬ 
gram"  option,  to  explore  the  "what  if"  under  consideration 
via  "Compute  Solution"  (see  Figure  13) . 
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Modeling  Windows 


Linear  "What  if"  Opportunity  Cost  Objective 

Program  Function: 

Z  =  2X1  +  3X2 

Build  a  Model 

Revise  a  Model  Constraints: 

Change  Data  XI  +  X2  =  1000 

Compute  Solution  XI  +  2X2  =  2000 

XI  +  3X2  =  4000 


Figure  13  Modeling  Windows 

The  independent  variable  XI  denotes  the  number  of  collateral 
test  procedures  impacted  by  waiving  the  given  test  proce¬ 
dure.  Similarly,  X2  is  the  number  of  engineering  change 
procedures  required  to  make  the  failed  device  test  compli¬ 
ant. 

The  first  constraint  limits  the  number  of  total  proce¬ 
dures  to  be  implemented,  while  the  latter  two  constraints 
bound  the  number  of  hours  for  planning  and  implementation 
respectively.  Both  XI  and  X2  are  positive  integer  values. 

(5)  Basic  Solutions  Window.  The  program  manag¬ 
er  is  provided  a  number  of  feasible  (all  variables  are 
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positive  integer  values)  and  infeasible  solutions  from  which 
to  choose.  Although  it  is  likely  that  the  infeasible  solu¬ 
tions  would  be  discarded  from  further  consideration,  several 
feasible  options  remain.  The  program  manager  will  now 
consult  with  test  and  engineering  to  try  to  determine  which 
of  these  options  is  most  practical.  The  ensuing  discussion 
might  result  in  a  less  than  optimal  solution  being  chosen 
due  to  factors  not  modeled  in  the  linear  program  (see  Figure 
14)  . 

(6)  Task  Menu.  The  program  manager  returns  to 
the  Program  Management  Task  Menu  to  set  up  a  meeting  via  LDN 
computer  conferencing,  by  selecting  "Meetings"  and  "Communi¬ 
cations"  (see  Figure  11) . 


Figure  14  Basic  Solutions  Display 
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(7)  Meetings  and  Communications  Menu.  Meetings 
and  Communications  options  are  displayed  in  the  Meetings  and 
Communications  Menu  and  "Team”  and  ’’Video  Conferencing"  are 
selected  (see  Figure  15) . 


Meetings  and  Communications  Menu 


Meetings 

1  Team 

2  Program  Management 

3  Engineering 

4  Logistics 

Communications 

1  Electronic  Mail 

2  Video  Conferencing 

Select  Options  <l-4,l-2> 
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Figure  15  Meetings  and  Communications  Menu 

(8)  Team  and  Meeting  Agenda  Menu.  The  program 
manager  selects  "Test"  and  "Engineering"  from  the  options 
listed  under  "Team"  and  all  of  the  options  under  Meeting 
Agenda  from  the  Team  and  Meeting  Agenda  Menu.  (see  Figure 
16)  . 


30 


Team  and  Meeting  Agenda  Menu 


Team 

1  Configuration  Management 

2  Director  of  Programs 

3  Contracting 

4  Engineering 

5  Logistics 

6  Manufacturing 

7  Program  Control 

8  Test 


Meeting  Agenda 


1 

2 

3 

4 

5 

6 


Problem 

Document 

Search 

Modeling 

Solutions 

Decision 


Figure  16  Team  and  Meeting  Agenda  Menu 


(9)  Conferencing  Windows.  In  Figure  17,  the 
test  manager  (upper  left.  Perry,  1989,  p.44),  and  the  engi¬ 
neering  manager  consulting  with  his  engineers  (lower  left, 
Santo,  1938,  p.  54),  appear  in  the  video  conferencing  win¬ 
dows.  The  meeting  agenda,  to  be  supplemented  with  other 
text,  graphics,  etc.  appears  to  the  right  of  the  figure. 

The  conference  will  either  conclude  with  a  decision  on 
whether  or  not  to  uphold  the  government's  position,  or  set 
the  stage  for  another  dialog  session  to  try  to  resolve  the 
problem.  The  video  conferencing  capability  affords  the  team 
instantaneous  face  to  face  contact  without  requiring  them  to 
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leave  their  work  areas.  By  remaining  in  their  work  areas, 
team  members  save  time  normally  taken  to  gather  at  a  sepa¬ 
rate  location,  in  addition  to  the  added  convenience  of 
having  immediate  access  to  their  work  areas,  should  the  need 
arise . 


Conferencing  Windows 

Meeting  Agenda 


Problem: 

-  Contested  contractor 
failed  test  procedure 

Document  Search: 

-  Test  Procedures 

-  Specification 

-  Contract 

Modeling: 

-  Linear  Program 

-  Solutions 


Decision  Alternatives: 

-  Amend  Test  Proce 
dures 

-  Uphold  Contract 


Figure  17  Conferencing  Windows 


2 .  Data  Base  Subsystem 

The  relational  data  base  incorporates  seven  primary 
relations  that  provide  task  performance  from  the  AGDSS 
terminal  corresponding  to  the  task  menu  discussed  in  the 
example  of  Subsection,  III  Clb.  These  relations  are: 

1.  Budget  -  containing  the  year  and  amount. 

2.  Schedule  -  records  the  type,  event,  start,  and 
finish . 
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3.  Meetings  -  logs  the  meeting  name,  date,  time  and 
location. 

4.  Problem  -  contains  the  problem  number,  description, 
priority,  and  urgency. 

5.  Correspondence  -  tracks  correspondence  number,  to, 
from,  date,  and  subject. 

6.  Documentation  -  includes  document  number,  page(s) , 
section,  and  paragraph. 

7.  Communications  -  holds  the  medium  and  link  data. 

In  addition  to  the  creation,  update,  and  retrieval 

operations,  the  data  base  shall  have  the  capability  to 
"extract"  data  from  external  sources.  The  extraction  proce¬ 
dure  produces  local  data  bases  which  are  subsets,  aggre¬ 
gates,  or  some  combination  of  the  two,  which  are  smaller 
than  the  source  data  bases  they  are  derived  from.  The 
reduced  size  combined  with  better  indexing,  provides  for 
faster  access  times  for  enhanced  system  performance.  These 
external  sources  might  be  within  or  outside  the  physical 
confines  of  the  AGDSS.  Since  the  data  base  is  distributed, 
each  of  the  functional  area  data  bases  would  be  considered 
external  to  the  program  manager’s  terminal,  yet  within  the 
confines  of  the  AGDSS.  In  the  example  of  Subsection  III 
Clb,  the  program  manager's  data  base  uses  extraction  (see 
Figure  18)  to  obtain  the  test,  specification,  and  contract 
documentation  from  test,  engineering,  and  contracting  re¬ 
spectively.  These  documents  are  maintained  by  the  respec- 
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documentation  from  test,  engineering,  and  contracting  re¬ 
spectively.  These  documents  are  maintained  by  the  respec¬ 
tive  functional  managers,  only  to  eliminate  redundancy  while 
ensuring  data  integrity.  Extraction  is  also  performed  on 
the  program  manager's  internal  data  base  files  containing 
program  status,  model  base  parameters,  and  correspondence. 

It  is  possible  that  data  extraction  could  include  external 


SOURCE  DATA 


Figure  18  AGDSS  Data  Base  Data  Extraction  Feature  from  the 
Program  Manager's  Perspective 
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connections  via  a  wide  area  network  (WAN) ,  to  other  partic¬ 
ipating  government  agencies  and  contractors.  Since  the 
program  manager  will  exchange  a  great  deal  of  information  up 
the  chain  of  command,  it  will  be  necessary  to  provide  ex¬ 
traction  between  the  program  manager  and  his  immediate 
superior,  the  director  of  programs,  who  will  be  connected  to 
the  AGDSS  as  well. 

3 .  Model  Base  Subsystem 

a.  Model  Base  Description 

The  model  base  will  consist  of  a  variety  of 
subroutine  like  building  blocks  as  mentioned  earlier  which 
can  be  combined  to  form  models  to  support  the  three  levels 
of  decision  making:  strategic,  tactical,  and  operational. 
Regardless  of  the  level  invoked,  the  same  basic  steps  for 
exercising  the  model  base  subsystem  occur  via  links  to  the 
dialog  subsystem  and  data  base  subsystem.  Intermodel  links 
also  exist  between  the  three  levels  when  called  upon. 

First,  the  model  is  selected  and  assembled  from  the  basic 
building  blocks  stored  in  the  model  base.  Once  assembled, 
the  model  loads  the  necessary  parameters  requested  by  the 
user  from  the  data  base.  Next,  the  model  is  executed, 
granting  the  user  the  option  to  interrupt  the  process  at  any 
time  to  check  intermediate  or  final  results,  or  to  change 
parameters  and/or  sequencing.  Upon  completion  of  execution, 
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the  model  places  the  results  in  the  data  base  and  signals 
the  user  that  it  has  finished  execution. 

b.  Example  for  the  Model  Base  Subsystem 

Following  the  example  from  Subsection  III  Clb, 
Figure  19  shows  the  three  levels  of  modeling  involved  in 
deciding  what  to  do  about  the  contractor's  failure  of  a 
government  test  procedure.  For  each  level,  the  first  column 
shows  the  inputs,  the  second  column  shows  the  extracted  data 
base,  and  the  third  column  shows  the  linear  programming  mod¬ 
el  employed  for  that  level. 

The  director  of  programs  strategic  model  and  the  test 
and  engineering  operational  models  are  separately  linked  to 
the  program  management  tactical  model.  The  director  of 
programs  having  updated  the  funding  data  with  the  latest 
Program  Objective  Memorandum  (POM)  figures,  is  concerned 
about  the  consequences  of  decisions  at  subordinate  levels 
which  affect  major  expenditures.  The  director,  after  a 
video  conference  with  the  program  manager,  may  decide  to  cut 
or  cancel  the  program  (which  might  obviate  the  problem  at 
the  subordinate  levels) ,  in  light  of  long  range  funding  and 
the  program's  status  and  priority  measured  against  other 
programs.  Recall  the  "what  if"  opportunity  cost  objective 
function  of  the  tactical  model  from  the  dialog  example, 
Subsection  III  Clb.  This  model's  data  is  updated  by  a 
contract  letter  which  establishes  the  objective  of  minimiz- 
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Figure  19  AGDSS  Three  Level  Model  Base 


ing  the  cost  to  the  government  of  upholding  the  test  proce¬ 
dure,  and  subjecting  the  government  to  contractor  claims, 
versus  changing  the  procedure  and  any  collateral  procedures 
to  accommodate  testing.  The  proposed  test  procedure  and 
design  changes  fed  into  the  data  base,  drive  the  operational 
model,  which  supports  the  tactical  model  by  providing  the 
constraints  to  the  latter  model's  objective  function.  These 
constraints  are  derived  by  exploring  possible  answers  to  the 
basic  questions.  First,  was  the  test  procedure  valid  or 
over  specified?  If  valid,  does  a  contractual  obligation 
exist  on  the  contractor's  part?  Finally,  if  so,  how  benefi¬ 
cial  is  it  for  the  government  to  pursue  consideration  from 
the  contractor? 

4 .  Outputs 

While  the  AGDSS  is  constantly  processing  input  and 
output  during  the  dialog  sequences,  it  is  also  accomplishing 
other  mundane  and  labor  intensive  tasks  with  much  greater 
efficiency  than  the  manual  methods  relied  upon  currently  to 
prepare  and  process  program  documentation.  In  the  example, 
the  program  manager  retrieves  excerpts  from  the  test,  speci¬ 
fication,  and  contract  documentation,  which  is  maintained  by 
the  functional  managers  via  the  AGDSS.  In  addition,  the 
AGDSS  will  record  dialog  sessions,  video  conference  meeting 
minutes,  and  other  historical  information.  A  serious  short¬ 
coming  of  meeting  minutes  currently,  is  the  tendency  for  the 
person  recording  minutes  to  omit  or  misinterpret,  key  infor- 
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mation  during  a  meeting  or  while  translating  a  tape  record¬ 
ing  of  the  meeting.  Furthermore,  the  minutes  review  process 
can  take  days,  even  weeks,  requiring  preparation,  distribu¬ 
tion,  review  and  correction.  By  the  time  the  minutes  become 
available  for  review,  the  events  that  transpired  are  no 
longer  fresh  in  the  minds  of  those  reviewing  the  minutes, 
making  it  nearly  impossible  to  judge  whether  or  not  the 
minutes  as  recorded  are  both  accurate  and  complete.  Incom¬ 
plete  and/or  inaccurate  minutes  are  a  prime  source  of  commu¬ 
nication  breakdown  and  its  related  problems  (see  Chapter  I, 
p.  2) .  The  AGDSS  will  preclude  human  error  in  recording  the 
minutes  and  the  expensive  and  time  consuming  review  process 
which  is  required  to  compensate  for  that  error. 

The  program  manager  as  well  as  the  functional  managers 
invest  significant  amounts  of  time  preparing  reports  and 
briefings  to  the  deputy  for  programs.  Much  of  their  effort 
would  be  replaced  by  the  AGDSS.  Relieved  of  the  mundane  and 
time  consuming  tasks  associated  with  preparing  view  graphs 
and  typing  reports,  the  managers  can  devote  their  time  to 
managing  their  functional  areas,  with  the  only  burden  being 
that  of  maintaining  the  AGDSS  data  base,  from  which  both 
timely  and  informative  reports  and  briefings  will  be  de¬ 
rived.  Thus  the  untimely  and/or  uninformed  decision  (see 
Chapter  I,  p.  3)  is  a  less  likely  result  of  AGDSS  generated 
reports  and  briefings. 
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D.  SUMMARY 


The  foregoing  example  demonstrates  the  advantage  a  deci¬ 
sion  support  system  can  afford  to  the  acquisition  group  in 
decision  making.  Through  the  dialog  subsystem,  the  director 
of  programs,  program  manager,  and  functional  manager  can 
effortlessly  contact  each  other  and  obtain  required  program 
document  references  without  filtering  important  information. 
Insights  provided  by  these  references  can  be  objectively 
modeled  to  arrive  at  a  set  of  timely  and  informed  alterna¬ 
tive  decisions.  Furthermore,  dialog  sessions,  such  as  the 
example,  can  be  archived  for  future  reference,  an  invaluable 
capability  which  has  no  equal  in  the  non-DSS  world. 
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1.  SCOPE 

1.1  Scope.  This  specification  establishes  the  performance  and 
interface  requirements  for  the  AGDSS. 

2 .  REFERENCED  DOCUMENTS 

2.1  GOVERNMENT  DOCUMENTS 


SPECIFICATIONS: 

Military 

SS-CSOC-OOOOIB 

84  Apr  16 

STANDARDS : 
Federal 

DOD-5200 . 28-STD 
December  1985 

Military 

AFOSH  STD  127-64 
79  Mar  03 
IMC  80-1 

81  Jan  19 

MIL-STD-4  54H 

82  Jul  30 
Notice  1 
82  Sep  01 

MIL-STD-4 9 OA 

85  Jun  4 


System  Specification  for  the 
Consolidated  Space  Operations  Center 


Department  of  Defense  Trusted  Computer 
System  Evaluation  Criteria 


Data  Processing  Facilities 


Standard  General  Requirements  for  Elec¬ 
tronic  Equipment 


Military  Standard  Specification  Practices 


2.2  NON-GOVERNMENT  DOCUMENTS 
SPECIFICATIONS:  Reserved 

STANDARDS:  Reserved 


OTHER  PUBLICATIONS: 

Bui,  T. ,  and  Jarke,  M. ,  "Communications  Requirements  for  Group 
Decision  Support  Systems,"  paper  presented  at  the  Nineteenth 
International  Conference  on  System  Sciences,  University  of 
Hawaii,  Honolulu,  Hawaii,  January  1986. 
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Bui,  T. ,  Jarke  M. ,  and  Shakun,  M.F.,  "Non-Cooperation  in  Group 
Decision  Support  Systems  Many  Problems  and  Some  Solutions," 
SCIMA,  Journal  of  Management  Science  and  Cybernetics.  V.  18,  Nos 
1-2,  pp.  51-63,  1989. 

Chorafas,  D.N.,  Computer  Networks  for  Distributed  Information 
Systems .  Petrocelli  Books  Inc.,  1980. 


NCSC-TG-005 
31  July  1987 


Trusted  Network  Interpretation  of  the 
Trusted  Computer  System  Evaluation  Criter 
ia 


NCSC-TG-008  A  Guide  to  Understanding  Trusted  Distribu 

15  December  1988  tion  in  Trusted  Systems 


Sprague,  R.  H.,  and  Carlson,  E.  D. ,  Building  Effective  Decision 
Support  Systems.  Prentice  Hall,  1982. 


3 .  REQUIREMENTS 


3.1  SYSTEM  DEFINITION 


This  specification  defines  the  performance  and  interface 
requirements  for  the  Acquisition  Group  Decision  Support  System 
(AGDSS) .  The  AGDSS  combines  such  key  technologies  as  locrl  area 
networks,  word  processing,  graphics,  data  base  management,  and 
video  conferencing,  which  can  free  acquisition  team  members  of 
mundane  paperwork,  and  afford  them  extraordinary  decision  making 
capabilities.  These  capabilities  promise  to  result  in  more 
timely  and  better  informed  decisions. 

3.1.1  General  Description 

The  AGDSS  is  composed  of  four  subsystems: 

Communications , 

Dialog, 

Data  Base,  and 
Model  Base. 

These  subsystems  are  discussed  below. 

3. 1.1.1  Communications  Subsystem  CCS1 

The  CS  provides  the  local  area  network  (LAN)  network  archi¬ 
tecture  functions,  interfaces,  and  protocols  (Chorafas,  1980, 
p .  74 )  .  In  addition,  the  CS  indicates  to  individual  DSS  not  only 
how  to  communicate,  but  also  what  type  of  information  should  be 
exchanged.  (Bui  and  Jarke,  1986,  p.  11) 

3. 1.1.2  Dialog  Subsystem  (PS) 

Dialog  between  the  user  and  the  DSS  is  accomplished  via  the 
DS.  The  DS  consists  of  facilities  to  perform  the  man-machine 
interface  of  the  AGDSS. 
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3. 1.1. 3  Data  Base  Subsystem  fDBS) 

The  DBS  contains  the  archives  for  documentation  as  well  as 
parameters  for  the  model  base. 

3. 1.1. 4  Model  Base  Subsystem  (MBS) 

The  MBS  utilizes  the  DBS  manipulation  language  to  assemble 
the  necessary  model  building  blocks  into  models  for  use  by  the  DS 
and  to  execute  those  models  with  parameters  input  via  the  DS . 

3.1.2  Mission 


The  mission  of  the  AGDSS  is  to  provide  acquisition  team 
integrity  and  the  necessary  information  processing  capacity,  to 
mitigate  the  impact  of  the  adverse  effects  of  communication 
breakdown  and  filtering  of  information,  on  acquisition  decision 
making. 

3.1.3  Threat 

The  system  is  subject  to  the  threat  described  in  NCSC-TG- 
008,  Version-1. 

3.1.4  System  Diagrams 

3. 1.4.1  Functional  Flow  Diagrams 


The  top  functional  flow  diagram  for  the  system  is  shown  in 
Figure  3-1. 
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Figure  3-1.  AGDSS  Top  Flow  Diagram 


3. 1.4.2  Specification  Tree 

The  specification  tree  for  the  system  is  shown  in 
Figure  3-2. 
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Figure  3-2.  AGDSS  Specification  Tree 
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3.1.5.  interface  Definition 


For  the  purposes  of  this  specification  an  interface  is 
defined  as  a  functional  relationship,  physical  connection,  or 
software/information  transfer  between  two  or  more  equipment/comp¬ 
uter  program  entities  within  a  system  or  between  a  system  and 
entities  external  to  it. 

AGDSS  interfaces  are  comprised  of  external,  intersubsystem, 
and  intrasubsystem  categories.  Interfaces  existing  between  AGDSS 
entities  and  entities  external  to  the  AGDSS  are  defined  to  be 
external.  Intersubsystem  interfaces  are  defined  to  exist  between 
AGDSS  subsystems  and  between  AGDSS  subsystems  and  the  Facilities 
Segment.  Intrasubsystem  interfaces  are  defined  as  those  which 
exist  between  entities  within  an  AGDSS  subsystem  (e.g.,  elements, 
subelements,  assemblies,  subassemblies,  components,  parts) . 

3. 1.5.1  Intersubsvstem  Interfaces 

AGDSS  intersubsystem  interfaces  excluding  the  Facilities 
Segment  are  shown  in  Figure  3-3.  The  DS  provides  the  MBS  with 
model  parameters  and  receives  model  results  from  the  MBS  via  the 
CS.  The  model  building  blocks  are  shown  leaving  the  DBS  and 
entering  the  MBS.  Finally,  double-headed  arrows  indicate  that 
documentation  and  queries  require  full  duplex  communication  ties 
between  the  DS  and  DBS . 

3. 1.5.2  External  Interfaces 


AGDSS  external  interfaces  are  shown  in  Figure  3- * 

3. 1.5. 3  Intrasubsvstem  Interfaces 

Intrasubsystem  interface  requirements  are  defined  in  the 
lower-tier  (SSS  &  SES)  documents  and  the  facilities  intrasegment 
requirements  are  defined  in  the  SD  document  of  the  specif ication 
tree . 


3.2  CHARACTERISTICS 

3.2.1  Performance  Characteristics 

3.2. 1.1  Interoperability 

The  interoperability  of  the  AGDSS  subsystems  will  be  pro¬ 
vided  by  the  intersubsystero  interfaces  (see  paragraph  3. 1.5.1). 

3.2.2. 1  Facilities 

The  AGDSS  Facilities  Segment  shall  be  as  specified  in  the 
Facility  Specification  (FS)  SD-AGDSS-00020 . 
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Figure  3-3. 


AGDSS  Intersubsystem  Interfaces 


Figure  3-4.  AGDSS  External  Interfaces 
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3. 2. 2. 2  Electrical  Power 

The  AGDSS  shall  be  provided  with  facility  power. 

3.2.3  Reliability 

AGDSS  mission  reliability  is  defined  as  the  probability  of 
successful  AGDSS  equipment  support  of  a  mission  for  a  specified 
time  period.  Quantitative  reliability  requirements  are  derived 
from  the  mean  time  between  critical  failures  (MTBCF)  of  the 
functional  equipment  and  the  time  duration  over  which  the  reliab¬ 
ility  is  specified. 

a.  The  following  guidelines  shall  be  used  in  interpreting 

the  requirements  in  this  section  and  in  3.2.4  and  3.2.5: 

(1)  The  reliability,  maintainability,  and  availability 
parameters  defined  in  this  specification  do  not 
include  any  impact  due  directly  or  indirectly  to 
actual  threats,  operator  errors,  or  software. 

(2)  Redundancy  may  be  used  to  obtain  the  required 
reliability  figures  if  the  redundant  element  is  on 
line  or  is  substituted  for  a  failed  element  in  a 
non-interrupting  manner,  or  if  automatic  or  manual 
switch-over  can  be  effected  in  a  period  of  time  and 
in  a  manner  that  allows  full  mission  continuance. 

(3)  AGDSS  equipment  shall  provide  levels  of  reliabili¬ 
ty,  availability,  and  maintainability  sufficient  to 
meet  the  applicable  requirements  of  the  AGDSS 
subsystems . 

3.2.3. 1  Subsystem  and  Facilities  Segment  Reliabilities 

The  AGDSS  Subsystems  and  Facilities  Segment  shall  have 
reliabilities  as  described  below. 

3. 2. 3. 1.1  Communications  Subsystem  Reliability.  The  Communica¬ 
tions  Subsystem  shall  properly  switch,  transmit,  or  receive  data 
or  voice/video  between  any  two  points  in  the  AGDSS  communications 
network,  with  a  reliability  of  0.9995  for  a  period  of  30  minutes. 

3. 2. 3. 1.2  Dialog  Subsystem  Reliability.  TBD. 

3. 2. 3. 1.3  Data  Base  Subsystem  Reliability.  TBD. 

3. 2. 3. 1.4  Model  Base  Subsystem  Reliability.  TBD. 
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3. 2. 3. 1.5  Facilities  Segment  Reliability.  The  AGDSS  shall  be 
provided  commercial  power,  environmental  control,  and  backup 
power  through  the  Facilities  Segment.  The  Facilities  Segment 
shall  have  the  following  reliabilities: 

a.  The  reliability  of  the  environmental  systems  (temper¬ 
ature,  humidity,  etc.)  shall  be  at  least  0.99998  for  a 
period  of  8  hours. 

b.  The  reliability  of  the  backup  power  system  shall  be  at 
least  0.9989  for  a  period  of  24  hours. 

3. 2. 3. 2  Mean  Time  Between  Critical  Failures 

A  critical  failure  is  defined  as  any  equipment  failure 
causing  an  unscheduled  interruption  which  prohibits  a  system  from 
successfully  completing  its  function  within  the  allocated  time. 
The  Mean  Time  Between  Critical  Failures  (MTBCF)  for  AGDSS  or  for 
any  AGDSS  subsystem  shall  meet  the  following  requirements: 

a.  The  MTBCF  shall  be  consistent  with  the  reliability 
requirements  specified  in  3.2.3  and  3. 2. 3.1. 

b.  The  MTBCF  shall  be  determined  using  actual  component  or 
device  failure  rates.  When  such  information  in  not 
available,  the  MTBCF  may  be  determined  analytically. 

c.  The  MTBCF  may  be  achieved  through  the  application  of 
redundant  equipment,  provided  it  complies  with  3.2.3a. 

3.2.4  Maintainability 

Preventive  maintenance  and  planned  configuration  changes  are 
classified  as  scheduled  maintenance.  The  AGDSS  shall  be  designed 
to  meet  the  following  maintainability  requirements: 

a.  Maintainability  shall  conform  to  the  reliability  re 
quirements  of  3.2.3,  3. 2. 3.1,  and  availability  require¬ 
ments  of  3.2.5. 

b.  Maintainability  shall  be: 

(1)  Predicated  on  the  necessity  of  continuous  opera¬ 
tions 

(2)  Consistent  with  the  logistics  requirements  in  3.5 

c.  All  scheduled  maintenance  shall  be  such  that  it  does  not 
interfere  with  the  support  of  critical  operations. 

d.  Life-cycle  costs  shall  be  a  major  consideration  in 
determining  maintainability. 
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3.2.4. 1  Mean  Time  to  Restore 

Mean  Time  to  Restore  (MTR)  is  the  average  time  required  to 
restore  a  function  lost  due  to  equipment  failure. 

a.  MTR  shall  include  both  switch-over  and  restoration  of 
the  system  to  the  minimum  configuration  required  to 
support  a  mission. 

b.  MTR  may  include  any  or  all  of  the  following  steps: 
isolation,  disassembly,  reassembly,  re-boot,  and  check 
out.  The  duration  starts  at  the  report  of  system 
malfunction  and  ends  at  completion  of  system  restora 
tion. 

3. 2. 4. 2  Mean  Time  Between  Maintenance  Actions 

Mean  Time  Between  Maintenance  Actions  (MTBMA)  is  the  total 
number  of  system  life  units  divided  by  the  total  number  of 
maintenance  actions  (preventive  and  corrective)  during  a  stated 
period  of  time.  The  MTBMA  for  each  subsystem  shall  be  (TBD) . 

3. 2. 4. 3  Maximum  Continuous  Downtime 

The  90th  percentile  of  downtime  distribution  of  a  given 
AGDSS  function  is  defined  as  Maximum  Continuous  Downtime  (Mmax) . 
Assuming  that  all  resources  for  support  of  a  given  function  are 
available  at  the  start  of  the  downing  event  and  that  maintenance 
personnel  are  on  site,  Mmax  for  both  scheduled  and  unscheduled 
maintenance  shall  not  exceed  the  following  values. 


Function 

Mmax 

MTBMA 

a . 

Communications  Subsystem 

60  minutes 

(TBD) 

b . 

Dialog  Subsystem 

30  minutes 

(TBD) 

c. 

Data  Base  Subsystem 

60  minutes 

(TBD) 

d . 

Model  Base  Subsystem 

60  minutes 

(TBD) 

3.2.5  Availability 

Availability  (Ao)  is  the  probability  an  item  is  in  an 
operable  and  committable  state  at  the  start  of  a  mission,  when 
the  mission  is  called  for  at  a  random  time.  Availability  re¬ 
quirements  are  established  in  terms  of  MTBCF ,  MTR,  and  Scheduled 
Maintenance  (SM) : 


Ao  =  MTBCF  /[MTBCF  +  MTR  +  (SM  *  MTBCF  /  SM  INTERVAL)] 
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SM  is  the  average  of  total  downtime  per  maintenance  inter¬ 
val,  resulting  from  preventive  maintenance,  overhaul,  and  other 
predetermined  maintenance  procedures  during  which  the  system 
cannot  perform  its  mission.  The  maintenance  interval  is  a 
periodic  time  interval  encompassing  both  the  downtime  durations 
and  the  elapsed  time  between  scheduled  maintenance  actions. 

When  scheduled  maintenance  can  be  scheduled  around  the 
required  subsystem  function  it  does  not  affect  the  availability 
and  the  term  involving  SM  is  correspondingly  zero  in  the  availa¬ 
bility  equation. 

a.  The  equipment  configuration  required  to  support  a  real¬ 
time  dialog  session  (single  or  multiple  user/system  in¬ 
teraction  without  video  conferencing)  shall  have  an 
availability  equal  to  0.995. 

b.  The  equipment  configuration  required  to  support  a  real 
time  dialog  session  with  video  conferencing  shall  have 
an  availability  equal  to  0.990. 

c.  The  Uninterruptible  Power  Supply  shall  have  an  availa¬ 
bility  of  at  least  0.99999  for  regulation  and  smoothing 
functions  and  0.99999  for  uninterrupted  power  supply 
functions . 

3.2.6  Environmental  Conditions 


Environmental  conditions  and  requirements  (physical  and 
space)  design  criteria  for  AGDSS  equipment  and  facilities  shall 
be  as  specified  in  the  Facility  Specification  (FS) ,  SD-AGDSS- 
00020. 


3.2.7  Security 

The  AGDSS  shall  provide  a  secure  operational  environment  to 
promote  mission  assurance  and  survivability,  and  to  protect 
classified  information  from  compromise. 

3. 2. 7.1  Information  Security 

The  AGDSS  shall  provide  capabilities  to  protect  classified 
information  against  unauthorized  modifications  or  disclosure 
commensurate  with  the  level  of  classification  assigned  under 
varying  conditions  which  may  arise  in  connection  with  its  use, 
dissemination,  storage,  movement  or  transmission,  and  destruc¬ 
tion  . 
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3. 2. 7. 2  Communications  Security 

The  AGDSS  shall  be  designed  to  provide  communications 
security  (COMSEC)  such  that  classified  information  transmitted 
over  internal  and  external  telecommunications  networks,  systems, 
and  circuits  shall  be  protected. 

3. 2. 7. 3  TEMPEST  Security 

AGDSS  equipment  shall  provide  TEMPEST  protection  to  control 
compromising  emanations  compatible  with,  and  not  redundant  to, 
the  TEMPEST  protection  provided  by  the  Facilities  Segment. 

3. 2. 7. 4  Automated  Data  Processing  System  Security 

AGDSS  automated  data  processing  shall: 

a.  Have  an  explicitly  defined  set  of  access  controls  based 
on  classification,  user  clearance,  and  established  need 
to  know. 

b.  Provide  users  (1)  access  to  all  the  information  for 
which  they  are  authorized,  and  (2)  deny  access  to 
information  for  which  they  are  not  authorized. 

3.3  DESIGN  AND  CONSTRUCTION 

Newly  designed  equipment  shall  be  designed  and  constructed 
in  accordance  with  high-quality  commercial  practices  except  where 
higher  quality  practices  are  specified.  The  AGDSS  shall  utilize, 
to  the  maximum  extent  practical,  equipment  and  software  already 
acquired  and/or  developed  for  acquisition  office  automation, 
consistent  with  achieving  cost-effective  design  and  development 
functions  and  maintaining  compatibility,  interoperability,  and 
supportability  at  the  AGDSS. 

3.3.1  Materials.  Processes,  and  Parts 

Materials,  processes,  and  parts  shall  meet  the  following 
requirements: 

a.  Commonality  in  materials,  processes,  and  parts  shall  be 
a  major  criterion  in  their  selection  to  minimize  the 
variety  of  parts,  related  tools,  and  test  equipment 
required  in  the  fabrication,  installation,  and  mainten¬ 
ance  of  the  system. 

b.  The  materials,  processes,  and  parts  selected  shall  be  of 
sufficient  proven  quality  to  allow  the  equipment  to  meet 
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the  functional  performance,  reliability,  and  strength 
requirements  during  the  applicable  life  cycle,  including 
all  environmental  degradation  effects. 

3. 3. 1.1  Parts  Standardization 

Standardized  off-the-shelf  parts  shall  be  used  wherever 
compatible  with  interoperability  and  life-cycle  cost  constraints. 

3.3.2  Safety 

Systems  safety  engineering  principles  to  provide  protection 
against  personal  injury  and/or  damage  to  equipment  shall  be 
applied  throughout  the  design,  development,  manufacture,  test, 
installation,  and  checkout  of  the  AGDSS  equipment  and  facilities 
in  accordance  with  MIL-STD-454H  where  applicable.  Occupational 
Safety  shall  be  in  accordance  with  AFOSH  STD  127-64. 

3.3.3  Expandability 

The  AGDSS  shall  be  developed  such  that  upgrading  of  capabil¬ 
ities  may  be  accomplished  without  degrading  on-going  operations. 

3 . 4  DOCUMENTATION 

AGDSS  documentation  requirements  are  as  follows: 

a.  Documentation  of  new  and  existing  equipment  and  software 
shall  support  design,  testing,  inspection,  installation, 
operation,  and  maintenance. 

b.  Existing  documentation  shall  be  utilized  where  practical 
when  software  or  equipment  components  are  replicated. 

c.  The  term  software  shall  include  firmware. 

3.4.1  Specifications 

The  AGDSS  specification  tree,  Figure  3-2,  shall  control 
lower  tier  specification  trees  for  system  subsystems  and  the 
Facilities  Segment  and  for  Configuration  Items  (CIs)  and  Computer 
Program  Configuration  Items  (CPCIs) . 

3.4.2  Drawings 


Drawings  shall  be  provided  as  follows: 
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3.4.2. 1  Program  Peculiar  Items 

New  design  shall  be  supported  with  equipment  drawings  and 
listings  sufficient  to  provide  remanufacture,  provisioning, 
fabrication,  installation,  and  reprocurement  activities. 

3. 4. 2. 2  Off-the-Shelf  or  Commercial  Equipment 

Drawing  information  shall  be  sufficient  to  support  main¬ 
tenance  and  repair  activities  and  to  permit  reprocurement  in 
accordance  with  subsystem/segment  contracts. 

3.4.3  Technical  Manuals 


Operation  and  maintenance  manuals  for  equipment  and  software 
shall  incorporate  levels  of  detail  compatible  with  AGDSS  staf¬ 
fing. 

3.5  LOGISTICS 

3.5.1  Logistics  Support 

The  AGDSS  shall  include  the  following  logistics  considera¬ 
tions  . 

a.  The  AGDSS  shall  be  designed  with  supportability  as  a 
major  criterion. 

b.  Provisions  for  a  maintenance  program  shall  be  made  to 
allow  flexibility  and  trade-offs  between  maintainability 
and  reliability. 

3.5.2  Maintenance 


AGDSS  maintenance  considerations  shall  include  the  follow¬ 
ing: 

a.  Design  shall  accomodate  maximum  utilization  of  component 
modularity  to  enhance  removal  and  replacement  mainten¬ 
ance  action  on  the  installed  equipment  and  minimize 
downtime . 

b.  All  Line  Replaceable  Units  (LRUs)  shall  be  readily 
accessible  to  ease  maintenance  action. 

c.  AGDSS  maintenance  shall  be  consistent  with  time  con¬ 
straints  imposed  by  mission  schedules. 

d.  The  AGDSS  design  shall  be  compatible  with  technician 
level  skill  requirements  for  maintenance.  The  mainten¬ 
ance  and  skill  level  requirements  will  be: 
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(1)  Determined  so  that  organizational/intermediate 
maintenance  can  be  performed  down  to  the  subassem¬ 
bly  level.  Design  will  accommodate  depot  level 
maintenance  to  the  part  level. 

(2)  Determined  by  Logistic  Support  Analysis  and  Repair 
Level  Analysis 

(3)  Established  in  accordance  with  the  AGDSS  mainten¬ 
ance  concept. 

e.  Design  shall  accomodate  the  employment  of  a  mix  of 
military,  in-service  civilians,  and  contractor  personnel 
to  carry  out  on-equipment  and  off-equipment  maintenance. 

f.  The  AGDSS  system  shall  be  designed  to  incorporate 
maximum  use  of  automated,  built-in  test/built-in  fault 
isolation  capability  to  diagnose  and  isolate  failures  to 
the  designated  LRU  level. 

g.  Where  automated  or  manual  support  equipment  is  required, 
government  inventory  items,  modified  inventory  items,  or 
commercial  off-the-shelf  items  shall  be  used  to  the 
maximum  extent  with  new  design  kept  to  a  minimum. 

3. 5. 2.1  Testability 

Provisions  shall  be  made  for  fault  isolation  tests  using 
automated  built-in  fault  isolation  capability  which  identifies 
the  failed  Line  Replaceable  Unit. 

3.5.2. 1.1  Test  and  Evaluation  Support.  Each  AGDSS  subsystem 
shall  provide  the  capility  to  support  individual  and  integrated 
testing  during  Development  Test  and  Evaluation  (DT&E) ,  and 
integrated  testing  during  Initial  Operational  Test  and  Evaluation 
(IOT&E) ,  and  Follow-On  Operational  Test  and  Evaluation  ( FOT&E) . 

3. 5. 2. 2  Scheduled  and  Unscheduled  Maintenance 

The  AGDSS  design  shall  accommodate  the  following  approach  to 
scheduled  and  unscheduled  maintenance: 


Scheduled  preventive  maintenance  and  engineering  changes 
without  interfering  with  critical  operations  support 

Unscheduled  corrective  maintenance  including  actions 
required  to  inspect,  service,  calibrate,  and  repair 
equipment . 
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3.5.3  Supply 

Supply  requirements  shall  be  integrated  into  the  development 
phase  of  new  or  modified  equipment  and  identified  during  the 
acquisition  of  commercial  equipment  to  establish  and  provide  a 
supportable,  cost-effective  logistics  system  for  all  subsystems 
and  the  Facilities  Segment  of  the  AGDSS,  compatible  with  the 
government  supply  system. 

3.6  PERSONNEL  AND  TRAINING 

3.6.1  Personnel 


Personnel  considerations  shall  include  the  following. 

a.  The  AGDSS  shall  be  designed  and  built  to  be  operated  and 
maintained  principally  by  military  personnel  not  ex¬ 
pected  to  have  extensive  scientific  or  engineering 
training.  In  addition,  DoD  civilian  and  contract 
civilian  personnel  will  be  used. 

b.  Personnel  not  possessing  data  processing  and/or  computer 
maintenance  backgrounds,  shall  be  provided  the  necessary 
prerequisite  training. 

3.6.2  Training 

The  AGDSS  shall  provide  training  capabilities  for  operations 
personnel  and  maintenance  personnel  to  the  performance  levels 
required  by  AGDSS  operations  and  maintenance.  Training  shall  be 
consistent  with  requirements  defined  in  the  AGDSS  Master  Training 
Plan . 

3. 6. 2.1  Operations 

3.7  FUNCTIONAL  AREA  CHARACTERISTICS 

3.7.1  Communications  Subsystem  fCS^  Operations 

The  CS  shall  provide  an  Application  Element  (AE) ,  a  Presen¬ 
tation  Element  (PE) ,  and  a  Network  Link  Physical  Element  (NLPE) . 

3.7. 1.1  Application  Element 

The  AE  functions  are  described  in  the  following  paragraphs 
which  contain  excerpts  from  Bui  and  Jarke,  1986,  p.  16. 

3.7. 1.1.1  Group  Norm  Monitor.  The  group  norm  monitor  shall 
provide  a  flexible  and  adjustable  mechanism  for  monitoring 
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communications  transfers  between  individual  DSS  to  predict  in 
advance  the  definition  of  group  decision  making  frameworks. 

3. 7. 1.1. 2  Group  Norm  Filter  £GNF) .  The  GNF  shall  enforce  the 
defined  protocols  of  the  Group  Norm  Constructor  (GNC)  whenever  a 
communication  activity  is  triggered  by  the  AG DSS  users.  When  a 
data  transfer  is  requested,  the  GNF  shall: 

a.  Check  whether  or  not  the  communication  desired  corre¬ 
sponds  to  the  preset  protocol. 

b.  If  the  request  is  in  accordance  with  the  protocols,  it 
shall  be  transferred  to  the  next  communications  routine. 

c.  Otherwise,  the  GNF  shall  notify  the  user  of  the  viola¬ 
tion  and  offer  him/her  the  current  communications 
protocols  pattern,  if  requested. 

3. 7. 1.1. 3  Invocation  Mechanism  (IM) .  The  IM  shall  provide  for 
modification  cf  the  communications  protocols  previously  set  via 
the  GNC.  The  IM  shall: 

a.  be  triggered  by  a  user’s  request 

b.  determine  when  and  how  to  convene  the  other  users  to 
debate  and  vote  on  the  motion. 

3.7. 1.2  Presentation  Element 

The  PE  function  is  described  in  the  following  paragraph 
containing  excerpts  from  Bui  and  Jarke,  1986,  p.  16. 

3.7. 1.2.1  DSS-to-AGDSS  Document  Formatter  fDADF) .  The  DADF 
shall  contain  to  the  extent  practical,  presentation  protocols  for 
any  possible  type  of  data  exchange  in  a  group  decision  situation. 
Examples  of  such  protocols  are  those  related  to  data  structures 
that  are  shared  between  the  individual  DSS  model  components  and 
the  AGDSS  model  component.  For  instance,  in  a  voting  procedure, 
data  must  be  compressed  before  being  reported  to  individual 
members . 

3.7. 1.3  Network  Link  Physical  Element 

The  NLPE  shall  perform  the  functions  of  layers  1-5  of  the 
Open  Systems  Interconnection  (ISO)  Reference  Model. 

3.7.2  PS  Operations 

The  DS  shall  provide  the  following  elements  as  described  in 
the  following  paragraphs  containing  excerpts  from  Sprague  and 
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Carlson,  1982,  pp.  214-216:  an  Output  Formatter  Element  (OFE) , 
an  Output  Constructor  Element  (OCE) ,  a  Device  Output  Functions 
Element  (DOFE) ,  a  Device  Driver  Element  (DDE) ,  a  Device  Input 
Functions  Element  (DIFE) ,  an  Input  Formatter  Element  (IFE) ,  a 
Response  Constructor  Element  (RCE) ,  and  a  Dialog  Data  Structure 
Manager  Element  (DDSME) .  The  values  and  attributes  associated 
with  the  function  of  these  elements  shall  not  be  specific  to  any 
interface  hardware,  so  as  to  permit  the  dialog  subsystem  to 
support  a  variety  of  hardware. 

3. 7. 2.1  Ouput  Formatter  Element 

The  OFE  shall  translate  commands  and  data  into  data  struc¬ 
tures  containing  the  values  (e.g.,  text  strings)  and  attributes 
(e.  g.,  color,  position,  size),  describing  the  output  represent¬ 
ations  (how  the  values  are  to  be  displayed) . 

3. 7. 2. 2  Output  Constructor  Element 

The  OCE  shall  translate  the  dialog  data  structure  into 
commands  to  create  an  output  representation  on  one  or  more 
devices. 

3.7.2. 3  Device  Output  Functions  Element 

The  DOFE  shall  generate  device-specific  commands  to  create 
outputs  on  one  or  more  specific  devices. 

3. 7. 2. 4  Device  Driver  Element 

The  DDE  shall  send  the  DOFE  commands  to  the  device,  wait  for 
user  inputs,  or  request  user  inputs  if  the  output  message  is  an 
interrupt  rather  than  commands  to  generate  a  representation. 

When  user  inputs  are  received,  the  DDE  shall  buffer  the  inputs 
and  send  the  inputs  to  the  device  input  functions  element. 

3. 7. 2. 5  Device  Input  Functions  Element 

The  DIFE  shall  translate  specific  inputs  into  device  inde¬ 
pendent  inputs. 

3. 7. 2. 6  Input  Formatter  Element 

The  IFE  shall  translate  the  user's  input  into  a  set  of 
action-object  pairs.  The  action  describes  the  user's  input 
action  (e.g.,  keyboard  keystroke).  The  object  designates  which 
object  in  the  output  representation  that  was  affected  by  the 
action  (e.g.,  new  value  or  attribute  for  a  menu  item). 
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3. 7.2.7  Response  Constructor  Element 

The  RCE  shall  use  a  set  of  action-object  pairs  to  create 
commands  and  data  for  the  other  components  of  the  DSS  e.g., 
update  a  data  base  field  corresponding  to  the  field  in  the  output 
representation  into  which  the  user  had  just  typed  a  new  value. 

3. 7. 2. 8  Dialog  Data  Structure  Manager  Element 

The  DDSME  shall  store  and  retrieve  data  used  by  the  dialog 
component,  such  as  the  data  structure  that  describes  the  output 
representation . 

3.7.3  DBS  Operations 

The  DBS  shall  provide  data  base  management  system  (DBMS) 
operations  utilizing  optimization  and  a  data  extraction  design. 
Optimization  techniques  such  as  automatic  file  reorganization, 
access  path  optimization,  and  operation  batching  shall  be  em¬ 
ployed  to  increase  the  performance  of  the  operations.  Data 
extraction  shall  provide  for  interfacing  a  variety  of  AGDSS 
source  data  bases  with  each  other.  The  DBMS  operations  are 
described  in  the  following  paragraphs  which  contain  excerpts  from 
Sprague  and  Carlson,  1982,  pp.  236-239:  a  Dictionary  Element 
(DE) ,  a  Creation  and  Deletion  Element  (C&DE) ,  an  Update  Element 
(UE) ,  a  Query  Element  (QE) ,  a  View  Element  (VE) ,  a  Protection 
Element  (PE) ,  a  Sharing  Element  (SE) ,  and  a  Recovery  Element 
(RE)  . 

3. 7. 3.1  Dictionary  Element 

The  DE  shall  support  data  base  dictionary  functions  such  as 
adding  new  entries,  deleting  entries,  retrieving  information  on 
the  entries,  and  maintaining  multiple  indices  (e.g.,  data  name, 
date  created,  responsible  organization) .  The  DE  functions  shall 
be  integrated  with  the  other  DBS  operations  such  that  for  exam¬ 
ple,  deleting  an  item  from  the  dictionary  should  result  in 
deleting  it  from  the  data  base. 

3. 7. 3. 2  Creation  and  Deletion  Element 

The  C&DE  shall  support  addition  and  subtraction  of  objects 
in  the  data  base  in  accordance  with  the  tvpe  of  creation  and 
selection  operations  permitted  by  the  data  base  model. 

3. 7. 3. 3  Update  Element 

The  UE  shall  permit  values  to  be  replaced  in  the  data  base. 
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3. 7. 3. 4  Query  Element 

The  QE  shall  support  the  selection  and  manipulation  of 
records  and  fields  in  the  data  base. 

3. 7. 3. 5  View  Element 

The  VE  shall  provide  customized  data  structures  (data  bases, 
records,  or  fields)  by  defining  a  subset,  aggregation,  or  other 
combination  of  the  data  base. 

3. 7. 3. 6  Protection  Element 

The  PE  shall  provide  restrictions  to  control  unauthorized 
usage  of  DBMS  functions. 

3. 7. 3. 7  Sharing  Element 

The  SE  shall  determine  how  many  users  can  have  simultaneous 
access  to  the  data  base.  If  sharing  is  permitted,  the  SE  shall 
provide  locking  functions  to  prevent  users  from  accessing  incon¬ 
sistent  data  and  preventing  "deadlock"  (preventing  each  other 
from  proceeding) . 

3. 7. 3. 8  Recovery  Element 

The  RE  shall  provide  the  capability  to  restore  the  data  base 
to  a  consistent  state  after  either  a  hardware  (disk)  failure  or 
after  a  software  (program)  failure.  The  RE  shall  checkpoint  and 
log  the  data  base  on  a  separate  file  for  recovery  purposes.  In 
the  event  of  a  failure,  the  data  base  shall  be  recovered  by 
applying  the  sequence  of  operations  in  the  log  (create,  update, 
and  delete)  to  the  most  recent  checkpoint. 

3.7.4  MBS  Operations 

The  MBS  shall  provide  a  model  base  management  system  (MBMS ) 
analogous  to  a  DBMS,  with  the  following  elements  as  described  in 
the  following  paragraphs  which  contain  excerpts  from  Sprague  and 
Carlson,  1982,  p.  262:  a  Generation  Element  (GE) ,  a  Restructure 
Element  (RE) ,  an  Update  Element  (UE) ,  and  a  Report  Generation- 
Inquiry  Element  (RG-IE) . 

3 . 7. 4 . 1  Generation  Element 

The  GE  shall  provide  a  mechanism  for  building  or  generating 
models.  This  mechanism  shall  be  designed  to  accommodate  change  in 
user  needs  as  well  as  technology. 
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3. 7. 4. 2  Restructure  Element 

The  RE  shall  provide  a  way  to  redefine  or  restructure  a 
model  in  response  to  changes  in  the  modeled  situation. 

3. 7. 4. 3  Update  Element 

The  UE  shall  provide  a  procedure  for  updating  a  model  in 
response  to  change  in  data  (e.g.,  a  revised  parameter  estimate 
without  change  in  structure) . 

3. 7. 4. 4  Report  Generation-Incruirv  Element 

The  RG-IE  shall  provide  for  operation  of  the  model  to  obtain 
the  decision  support  desired.  Alternative  forms  may  be: 

a.  Periodic  run  of  a  well-established  model 

b.  Special  results  from  an  ad  hoc  model 

c.  Use  of  data  analysis  models 

d.  Iterative  rerun  of  a  model  or  set  of  models 

e.  The  sequential  run  of  a  set  of  interrelated  models 
according  to  a  predefined  procedure. 

3 . 8  PRECEDENCE 

3.8.1  Conflicts 


In  the  event  of  conflict  between  the  documents  referenced 
herein  and  this  specification,  the  contents  of  this  specification 
shall  prevail.  Unresolved  conflicts  shall  be  directed  to  the 
contracting  officer  or  delegated  representative  for  resolution. 

4.  QUALITY  ASSURANCE  PROVISIONS 

Quality  assurance  provisions  shall  be  performed  in  a  manner 
consistent  with  the  requirements  of  this  specification. 

5.  PREPARATION  FOR  DELIVERY 

Not  Applicable. 

6 .  NOTES 

Reserved . 
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